Interactive television systems provide a means to deliver interactive content as well as ordinary television audio and video programs to a large number of subscribers. Programs broadcast by these systems may incorporate television audio and video, still images, text, interactive graphics, data, executable applications, locators, metadata and many other components. The interactive content of the interactive television program may therefore include application code, data associated with the audio and video, control signals, additional audio and video, still images, text, raw data, internet addresses and many other types of information.
Interactive content such as application code or information relating to television programs is often broadcast to a receiver, retrieved on demand from one or more servers at a remote site, or stored locally. In an on-demand interactive system, a return path is necessary for sending requests from a client to a server and subsequently retrieving the interactive content from the server. Once retrieved from the server, the supplemental content is received by the receiver and displayed on the same screen concurrently with the audio video program or may, alternatively, replace the audio video program, for example. Alternatively, a second device (such as a PC, PDA, web tablet, web phone, etc.) can be used to present the supplemental content. Further, while the interactive application can be fetched-on demand and forwarded over the same transmission service as the broadcast program, it could also be fetched and forwarded to the receiver station from a separate network. For example, the interactive application could be fetched and received from an online information provider, such as the Internet, while the audio video program is received over a conventional broadcast cable system.
When interactive content is broadcast, the interactive content is usually broadcast in a repeating format. In other words, each piece of information is broadcast a first time, then each is transmitted a second time, and so on. The cycle is repeated so that each piece of interactive data is transmitted, for example, every ten seconds. The pieces of information which are broadcast in this manner form what is referred to as a “carousel.” The sequence of information that makes up the carousel can be prepared in advance, or it can be determined “on the fly.”
Broadcast systems (e.g., interactive television systems) transmit information in a carousel format in order to allow receivers in the system to selectively obtain particular pieces of information in the carousel without requiring a return path from the receivers to the server. If a particular receiver needs a particular piece of information, it can simply wait until next time that piece of information is broadcast to obtain the information. If the information were not cyclically broadcast, the receiver would have to transmit a request for the information to the server, thus requiring a return path. Other receivers in the system can operate in the same manner, each receiver waiting for the information it needs, and then using only that information. By employing carousels to broadcast information, the system eliminates the need to connect each of the receivers with the server and further eliminates the need for the server to process individual requests for information.
If information needed is not cyclically broadcast, the receiver, if equipped with a suitable modem, could transmit a request for the information to a server, using what is called a return path. Other receivers in the system can operate in the same manner, each receiver waiting for the information it needs, and then using only that information.
The pieces of information, or data objects, in a carousel are often intended to be combined to form a single program. For example, an interactive television game show may combine audio, video and interactive content, such as application code which allows users to answer questions and compete against each other. The application code may be downloaded along with the data for the quiz show for example, or may reside locally, either on the device used to process the data or somewhere accessible on a home network, for example. Another example of an enhancement would be a news program which combines audio and video with application code that inserts current stock prices in a banner at the bottom of the screen. (It should be noted that many types of programs are possible, and it is not necessary to include either audio, video or interactive content in any particular program. A program might contain only audio and interactive data (e.g., an interactive radio program,) or it might contain only interactive data (e.g., an interactive weather program that does not contain audio or video streams.)
Various recording and playback devices, such as personal video recorders (PVRs), have been developed and commercialized in recent years allowing a viewer to “fast-forward”, “rewind”, “replay” or “pause” an audio video program when the viewer of the broadcast is monitoring the programming concurrent with its reception. These systems typically use memory devices such as a hard disk for storing the audio video program and playing back the program with near-perfect quality.
A control device on a typical PVR, for example, maintains the addresses of segments of the recorded program in the memory device, so they can be reassembled in the proper sequence for playback. Audiovisual display is controlled by user interaction. The control device is responsive to commands received from the viewer. Control of such a memory device to implement the various desired functions set forth above ate well known within the skill in the art.
The problem with current interactive television systems is that because a viewer controls the audiovisual display by viewer interactions, if a viewer wants to interact with an enhancement due to an interactive application, the audiovisual program will continue playing notwithstanding the viewer's lack of attention. In this manner, the viewer may miss portions or an entire commercial, for example, unless the viewer immediately upon interaction with the interactive TV application specifically commands the program to stop and then later indicates that they desire to resume viewing of the program. Even if the commercial continues to play on the screen, the viewer is now expressing interest elsewhere.
Accordingly, a need exists for a system and method that allows a viewer to interact with an interactive application without missing material in the currently played audiovisual program.
Another problem is that current PVR systems are not adequately designed to handle enhanced programming when using “trick” modes. Prior to the advent of PVR technology, it was safe for applications to assume that they always were run at the same time as they were broadcast, and that the program they are a part of progressed as a constant and well-understood rate. Therefore, many existing applications have explicitly or implicitly included assumptions that these facts are true, and will not run properly if they are played back at a different time or different rate from how they were originally broadcast, e.g., trick mode operations. Trick mode operations are basically any operation which change the speed or direction from normal forward playback. This also includes setting the playback to a different playback position. These assumptions are not a strict either-or proposition. Some applications may be able to handle some changes in these parameters and not others (for instance, an interactive application may be able to handle being played fast-forward, but not rewound; or an interactive application may be able to handle being played back at a later date, but only if it is played back at a constant rate).
In addition, some interactive applications will only be able to handle these changes if they remain in control of when and how the changes occur—doing their own processing of the pause, play, rewind, and fast-forward keys. This is potentially at odds with the network's interests to control those behaviors, either to ensure consistency or to support particular business models (like paying extra for the right to fast-forward through commercials). However, even with such networks, there may be a few applications that the network trusts to do their own trick-mode processing.
Further, because the program may include different interactive applications which are in various states throughout the program, it is necessary to maintain the proper states for these applications, even when parts of the program are skipped in special playback modes. Further, the applications may interact with other data objects, so it may be necessary to generate signals that would not otherwise be generated in a special playback mode.
It is possible to write applications that properly handle special modes, as long as the application receives proper notification of any changes in the location/rate of playback. However, this takes some effort on the part of the application developer, and not all developers will be willing to make the effort to support all special modes. Thus, it becomes necessary for the system to take action to handle applications that am unable to handle trick modes.
Yet another problem with current PVR systems is that they are unable to adequately integrate the use of “trick” modes when recording variable rate streams. The use of trick modes typically requires metadata that indicates the correspondence between play-time and location of the data on the recording media. For example, if a user wishes to use a trick mode to jump ahead 30 seconds into the programming, metadata that indicates where to jump to on the recording medium is required.
The usual approach for keeping track of the correspondence between play-time and location of the data on the recording media is to maintain a map from play time to stream offset (or file location). Consequently, the ability to randomly access through the file can be facilitated by maintaining a table of times and offsets, where in order to access to time T in the stream, the file must be played from the offset O. Thus, a file can be considered as having an ordered list of pairs T(t), O(i) for the stream. Normally, it is not difficult to build such an ordered list within a set top box when the stream is being sent at the rate at which it is meant to be played back. This is because the correspondence between T(i), O(i) follows a single formula. However, when the stream is being “dripped” at a variable rate, the correspondence is not constant. Accordingly, a need exists for determining the correspondence between play-time and location of the data on the recording media for a program recorded at a variable rate.